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ABSTRACT 

A project management procedure used in conjunction 
with the IBM Program Control System (PCS) is described. Information 
is given on hov the combination is used by the Florida Department of 
Education to control the cost of data processing projects and to 
ensure their completion on ^schedule. The first section of the paper 
describes the project management procedures, discussing background 
material, the Information Systems Section of the Department of 
Education*, and needs identified by the Section. Also reviewed are the 
soven phases of the management procedure: 1) problem analysis; 2) 
problem definition; 3) systems analysis; 4) systems design; 5) 
program specifications; 6) programing and implementation; and 7) 
systems evaluation. The second part of the paper deals with the 
Project Control System, with emphasis upon network and system 
concepts. The concluding section of the report describes the 
application of the project management procedures and the Project 
Control System to the development of a large computer-based system 
run by the Florida Department of Education. Topics discussed include 
the history and development of the computer system. A summary and 
some conclusions are also presented. (PB) 
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INTRODUCTION 



One of the most discussed, but also one of the most elusive topics 
in data processing in the past few years is project management or project 
control. Seminars have been devoted to this topic; it has been discussed 
at conventions; project management courses have been offered; books have 
been written about it. Typical observations are, "data processing projects 
never finish on schedule", and "these projects end up costing at least twice 
as much as originally planned." These observations are indicative of the 
two primary purposes of project management which are: 

1. Completion of the project within the schedule, and 

2. Control of the cost of the project 

Indeed these two purposes are interrelated to the extent that our 
presentation will consider both as one and the same. If a project is 
completed on schedule, it follows that project development cost is 
controlled. This will hold true unless extra resources must be applied 
in order to meet the schedule. 

To my knowledge, there is no panacea for good project management. 
What is advocated here may not be appropriate in every situation, but 
the Florida Department of Education has developed a technique that has 
worked. This technique is a well-defined project management procedure 
coupled with a computer assist from the IBM Project Control System (PCS). 
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This presentation will be made in three parts. The first two parts 
will describe the technique, while the third part will demonstrate the 
application of the technique to a major computer system development 

PROJECT MANAGEMENT PROCEDURES 

The Information Systems Section 

To understand our project management and control procedures, it is 
essential to have an understanding of the role of the Information Systems 
Section and the environment in which it functions. The Florida Department 
of Education is primarily composed of the following four divisions: Elementary 
and Secondary Education, Vocational Education, the Community Collage System, 
and the University System. The Department also has a significant number 
of agencies whose function is to support these divisions. The Information 
Systems Section is one such organization and its primary function is to 
provide data processing and related services to all other agencies of the 
Department. 

Background 

Several years ago our shop was run in a rather "slipshod" fashion. 
At the time we were, of course, unaware of this. We were never able to 
meet deadlines; the manpower requirements to maintain and modify poorly 
designed systems was greatly restricting the number of new systems which 
could be developed; and inefficient use of the computer was the rule, 
rather than the exception. We found ourselves turning down projects 
because we just didn't have time. In reality, we didn't know for certain 
whether we had tirra or not, because we were not sure when our current 
projects would be completed, nor the amount of time future planned 
projects would require. One of the obvious results of this "firefighting" 
was that our image was very low. In other words, the general feeling 
around the Department of Education was that we could not produce. 

We came to the realization that something had to be done, but the 
question was what? We were certainly aware of the steps required to 
complete our primary task: systems development. Some of these, of course, 
are problem definition, analysis, design, and progranming. But how do we 
manage this development? Within each of these areas or activities, there 
are problems. We decided that we must identify these problems if we were 
going to overcome them. 

Needs Identified 

After studying the situation, it seemed that all of the problems 
could be classified into the following tw(?lve needs which had to be 
satisfied. 

1. Management involvement in all phases of developme nt. 

It was imperative that we get management more mvoTved in the 
development process. 

2. Well -stated objectives . These needed to be written down, understood 
and agreed upon by all parties involved. 

3. Accurate estimate of project cost . We must be able to better 
project the manhour and computer requirements for every system 
under development. 



4 . Checklist to assure that critical phases are not overlooked . 
Not only will the checklist prevent an inadvertent omission of 
an activity or item, but it will help to insure an organized and 
systematic approach to each phase of development. 

5 . Management understanding and acceptance of lead times and costs . 
Management must be kept informed of the progress of development. 
They should never be surprised with extreme overruns in either 
time or cost. 

6. Clear-cut evidence of completed milestones . Everyone involved 
should be aware when a phase is completed. The activities of 

a phase should not begin until the preceding phase has been completed. 

7 . A means for communicating system and programming specifications . 
It is very difficult to verbally communicate between analyst and 
prograrrmers. It is even more difficult to effectively coimunicate 
between systems personnel and user personnel. Consequently, 
almost all communications need to be in writing to enhance the 
effectiveness of communications. 

8. Review by experienced personnel . Both managerial and technical 
personnel need to have an opportunity to review development 

at various points to insure that the best operational and technical 
approach is being incorporated. 

9. Time for review by many people . Time must be available for all 
individuals who will be directly involved to become oriented 

to the new system. 

10. Formality and rigor in reaching clear-cut decisions . 

The administrator needs to know when a decision is requi red . 
Management must be the one who makes the decision; this responsi- 
bility cannot be abdicated. 

11. An elimination of controversy over system deficiencies . 

Even if the deficiencies can t be eliminated, the controversy 
can be. 

12. A method useful for contract administration . 

a"! To overcome misunderstandings between customer and contractor. 

b. To alert both to slippages. 

c. To enable timely action to be taken by both. 

d. To assure management control which otherwise may be lacking. 

To this list another consideration should be added: flexibility. 
We had to control projects without ourselves being controlled. We realized 
that no fixed procedure could be developed which would handle every situation 
that could arise. Our staff had to have the capability of exercising judgment 
upon individual situations. 

The Procedure 

Having identified our needs, we had to determine how best to satisfy 
them. We began a search of literature, books, and the approaches used by 
other installations. Our two best sources were Administering and Controlling 
the Company Data Processing Function by Leonard I, Krauss (l), and the 
TRB & S Systems Management Series from Touche, Ross, Bailey, and Smart. Inc. (3) 



Now let's look at the Project Management Procedure. As we view this 
procedu^^e, please keep in mind two im,iortant features: 



1. The delivery of a paper or a document to the user signals 
the completion of a phase. 

2. The user is involved and must agree to some specification 
before the next phase is initiated. 

The phases which are briefly described below constitute our Project 
Management Procedure. Each phase is graphically illustrated in Figures 
1 through 7. 

I. Discussion and Problem Analysis (Figure 1) . The results of 
consultation between staff members of the user's organization and Information 
Systems is a Requirement Statement. This statement summarizes a problem 

or potential system and requests a study to determine if the develop- 
ment of a system to satisfy these needs is economically, technically, 
and operationally feasible. If the Requirement Statement is approved 
by management (of the user's organization), a letter of authorization 
is forwarded to Information Systems. However, should management wish 
to alter or modify the Requirement Statement In any way, they can do so. 
The option is also available at this point to terminate the project. 

II. General Problem Definition and Development Plan Preparation (Figure 2) . 
A Feasibility Study and Development Plan 1s the result of this step. 

Included among the items contained in the Development Plan are such things 
as a problem statement, a statement of assumptions and constraints, gross 
estimates of development costs and manpower requirements, a tentative comple- 
tion date, and a statement of the benefits (tangible and intangible). This 
document is submitted to the user for approval. A letter of authorization 
is sent if approved; if not approved, new guidance may be offered, or the 
project may be terminated. 

III. Systems Analysis (Figure 3) . The document resulting from systems 
analysis is the Functional Specifications. Included in this document are 
a revised problem statement, a layout of each type of input and output, a 
preliminary test plan, and a preliminary implementation plan. This document 
must also be approved by the user. 

IV. System Design (Figure 4) . The output of this step is the System 
Specifications. Among the items included in this document are a system 
resume, a system flowchart, record summaries, input and output summaries, 
and form designs. System Specifications are subjected to a technical review 
to assure that the approach adopted is as efficient and technically 

sound as possible. Following the technical review, the System Specifications 
are submitted to the user for approval. 

V. Preparation of Program Specifications (Figure 5), Detail 
specifications are prepared for every program specified in the system 
design. These documents are designed to enable a programmer to code the 
program with very little additional information. As they are completed. 
Program Specifications are forwarded to the user to obtain his approval. 

VI. Programming and Implementation (Figure 6) . This phase includes 
the preparation of program documentation, operations documentation, and 
user documentation. Also during this phase the system test plan and con- 
version plan (if applicable) are executed. Another element of significance 
is the preparation of briefing materials which will assist in user 

training and orientation. When all of these activities have been sur^cessfully 
concluded, the system can become operational. 
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VII. System Performance Evaluation (Figure 7) . Depending upon the 
system, an evaluation of the system performance should be conducted 
sometime between six and twelve months after implementation. The evaluation 
report which is prepared should include: 

A. A comparison of the planned versus the actual pv-^'^ormance; 

B. an evaluacion of the degree to which the objectives are being 
realized; 

C. a comparison of planned versus actual costs in time, resources 
and dollars; 

D. suggested improvements for future consideration. 



Summary 

While this procedure does not provide a means for tracking progress 
within a phase, it does give each phase a definite beginning and ending 
point. It insures coordination and mdnagement involvement. It also keeps 
decisions current and on record, and prevents delegation of decision 
making to programmers. Finally, it helps maintain good relations with 
customers. The latter is evidenced by the fact that some of the same people, 
who several years ago were our biggest critics, are now our biggest boosters. 

The following section will explain the computer-assisted technique 
for tracking or controlling systems development. 

PROJECT CONTROL SYSTEM (PCS) 



Information Systems decided to use the IBM Project Control System 
(2) in the development of the Federally Insured Student Loan System. 
The purpose in using PCS was to determine its value as a tool in planning 
and controlling the development of large computer-based systems. It was 
the first time this kind of tool was used in a major project. Information 
Systems uses IBM's Project Control System as a PERT system. Most people are 
aware of the PERT background. But for those who are unfamiliar. PERT stands 
for Program Evaluation and Review Technique. It was developed in the late 
1950*s and initially designed as a reporting technique to evaluate and 
monitor progress in the development of the Polaris missile system. The 
Polaris was the first missile to be launched from a submarine underwater. 
Other similar systems for planning and controlling projects have been 
developed such as Critical Path Method (CPM), Network Analysis and Precedence 
Network. Differences between these systems have all but disappeared; 
indeed PCS distinguishes only between PERT/CPM and Precedence Networks. 



Netv/ork Concepts 
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Figure 8, entitled NETWORK SHAPES, better illustrates this distinction. 
First, a definition is in order - work item . A work item is any distinct 
unit of work that must be performed during the course of a project. In 
a precedence network, work items are represented by nodes; in a PERT/CPM 
network, work items are represented by lines that connect the circles or 
nodes. Work items are commonly referred to as activities. Using this 
distinction, the networks represented are PERT or CPM type networks. 
That is, each activity is represented by a line identified by a job 
number. In this instance the term job was used because of its short 
length. Work item or activity could have been just as easily used. In the^ 
upper network (a network must be constructed for each project) job or activity 
A -^s represented ty the line between nodes 1 and 2; job H by the line between 



537 



FLORIDA DEPARTMENT OF EDUCATION 
Project Management Procedures 



Discussion and 




Problem 
Analysis 


(: 




Letter of 
Authorlzc- 
tlon to PXO: 
ceed 



FIGURE 1 



FLORIDA DEPARTMENT OF EDUCATION 
Project Management ?rocedures 



General Prob- 
lem Definition I 
and PreparatiajF" 
of Development 
Plan 



Feasibility 
Study and 
Development 
Plan 



lanagement 
Approval 



No 



Yes 

"New 
Guidance 



(End of A 
Project J 



Letter of 
Authoriza- 




PIGURE 2 
7 



539 



FLORIDA DEPARTMENT OP EDUCATION 
Project Management Procedures 



System 
Analysis 



Functional 
Specifica- 
tions 




Letter of 
Approval 



ERLC 



FIGURE 3 
8 



FLORIDA DEPARTMENT OF EDUCATION 
Project Management Procedures 



Systvam 




Design 


^ 1 



System 





Letter of 
Approval 




FIGURE 4 



FLORIDA DEPARTMENT OF EDUCATION 
Project Management Procedures 

Preparation of 

Program Speci-^^^ 

f ications 



Program 
Specifica- 
tions 



Technical 
Review 



Yes 




ERLC 



iGURE 5 
10 



FLORIDA DEPARTMENT OF EDUCATION 
Project Management Proceduras 



Progranuning , 
Test Planning, 
Conversion 
Planning 




Testing 
Reviewing 
Coordinating 



User 
Training 



FIGURE 6 
11 



543 



FLORIDA DEPARTMENT OF EDUCATION 
Project Management Procedures 



System 
Performance 
Evaluation 



Evaluation 
Report 





FIGURE 7 
12 



NETWORK SHAPES 
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5 and 6. The lower network is constructed in the same manner but with 
more activities^ The Federally Insured Student Loan network was constructed 
in the same manner, except that here were ninety-eight activities initially. 
In PCS or any other system you have to construct the network by hand. The 
network drawing for FISL encompasses a rather large sheet of paper, about 
one foot wide by five feet long. As a matter of fact, in order to construct 
the network, each activity in the network was identified and written on the 
back side of punched cards. Then the cards were laid out on the conference 
table, inter-relationships established between activities and each end of 
each card numbered. Therefore, the first activity was numbered 1, 2, the 
second 2, 3, etc. This is a slight oversimplification, but not far from 
the truth. PCS output reports show that actual activity identification 
is a four-character alphameric number. 

The original FISL network was made up of 98 activities. Subsequent 
modifications have increased the number of activities to the present one 
hundred fifteen (115). 

PCS Concepts 

PCS is a computer system that calculates a project schedule and then 
allows that project schedule to be updated and maintained as conditions 
in the project change. It is an extremely flexible system in that 
almost any element in the network can be modified or changed. It uses the 
concept of defaults so that unnecessary data nepd not be entered. Even 
the structure of the network itself can be modified. The flexibility 
of the system is further emphasized by the number of different output 
reports (14) that can be generated. There are also a generous number of 
report sequences offered. 

In the FISL project, only five of the available reports are used. 
These are the ones that have been most useful . Just remember that the 
system is capably of producing many other report types. Weekly update 
time, that is CPU clock time, averages between seven and eight minutes 
on the Knott Data Center 360/40. This is a modest expenditure for this 
very valuable tool. 

The two primary users in the FISL system receive copies of the weekly 
PCS reports. One of the most important characteristics of PCS is that it 
enables the user to clearly see significant inter-relationships between 
activities that must be performed on the project. 

There are nine major properties associated with a work item. 
These are: 



1. 


description 


2. 


time frame 


3. 


work dates 


4. 


duration 


5. 


percent complete 


6. 


float 


7. 


codes 


8. 


cost 


9. 


milestones 



Three of these properties should be addressed before output reports 
Q are discussed. The first of these is the concept of duration. Duration 
ERXC length of time needed to complete the work item. It may be expressed 

"sST" 14 



initially in terms of hours or days. If expressed in hours, as was done 
in FISL, PCS converts hours to eight-hour days. This conversion must be 
taken into account when constructing the network. It should be emphasized 
that the PCS network will be only as good as the estimated durations for 
each work item. One further point should be remembered. When estimating 
project durations, the number of resources to be applied should be consider- 
ed. If, for example, a work item entitled Programming - Phase 1 is to take 
1000 manhours, the number of programmers expected to be used on this activity 
will determine duration. If five programmers are to be used, then dividing 
1,000 by 5 equals 200- Duration then would be 200 hours, rather than 1,000. 

The second property of a work item or activity is float. Float can 
be described as the number of days between the early and late start or 
early and late completion of an activity. It is sometimes referred to 
as slack time. Float is non-critical time or extra time. 

The third property which merits some explanation is milestone. A 
milestone is the start or completion of a particular work item which is of 
major importance to the project. Start or completion of an activity is 
sometimes called an event. 

Two other notions should be briefly mentioned. The first of these 
is the notion of critical path. The critical path is the mst time- 
consuming path of activities from the beginning to the end "of the network. 
Any delay in the start or completion of a critical activity will delay 
completion of the project. The second notion is that of a calendar. 
It is necessary to recognize non-working days, whether these are holidays 
or any other specified nonwork day. These are recognized in the network 
scheduling process by establishing a project calendar. Indeed, if a 
schedule is to be realistic, non-work days must be recognized. 

PCS System Inputs and Outputs 

Sample inputs and outputs from PCS are available from the author. 

PCS Summary 

Project Control System/360 Is one of the diminishing number of free 
IBM software products. It has beer designed to operate as a DOS background 
program with a minimal set of operational and job control language 
requirements. The minimum configuration required is a 32K IBM 360 
(PCS, itself, requires 25,448 ^bjrtes of core memory), two 2311 disk drives 
(or 1 if SYSRES is" on 2314 or other), console typewriter, card reader, punch 
and printer. The IBM/PCS/360 manual number is #GH20-0376-3 and the program 
number is 360A-CP-06X. It is available on 7 or 9 track tape, 800 or 1600 
(9 track only) B.P.I. , or on a 1316 disk pack. 

PCS is a versatile, flexible tool in planning and controlling large 
computer-based systems development. It enhances the planning function by 
forcing recognition of all activities that have to be accomplished and 
their interrelationships. It facilitates control of the project by 
providing up to the minute information on project status. 

The next section describes the application of the two techniques, 
project management procedure and project control system, to the development 
of a large computer-based system. 

Er|c 15 
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FEDERALLY INSURED STUDENT LOAN SYSTEM 



The Florida Loan Program 

The Florida Insured Student Loan System, as it is known in Information 
Systems, is a program in which students at post-secondary educational 
institutions in Florida can borrow money from the Florida Department of 
Education (DOE). The DOE is an approved lender in accordance witti federal 
statutes which enrbles it to participate in the Federally Insured Student 
Loan Program. Th<.' Florida Legislature has, in effect, placed the DOE in the 
installment loen Imsiness* Applicants for loans from the DOE must comply 
with the restrictions placed upon them by both federal law and Florida 
statutes. In general, the Florida statutes closely follow the regulations 
established for the federal program. 

History 

This program was first proposed to the Florida Legislature in October 
1971. In December 1971, during a special session of the Legislature, it 
was decided to put the question to the people of Florida on the presidential 
primary ballot in March 1972. In the resulting vote the proposal was 
approved by a 65% to 35% margin. During the regular legislative session 
in the summer of 1972, the program was approved and funding was authorized 
by the sale of bonds up to forty million dollars. The DOE was approved 
as a lender by USOE in November 1972. The first bonds were sold ($8,000,000) 
in February 1973. Additional sales of bonds are scheduled for each of the 
next three years (1974-76). As of April 1, 1973, approximately 750 loans 
had been made by the DOE totaling about $1,000,000. 

Why Not Banks? 

Why are banks not used as in other states? This is usually the first 
question asked, and the answer is that banks are participating in the program. 
Banks in Florida are annually lending about $20,000,000 however, this is about 
the maximum that can be expected. One reason for this is that banks are 
not anxious to become involved in the program because of the long-term loans 
that bear a relatively low interest rate. Banks, of course, are primarily 
interested in short-term loans which yield a high return. Another contributing 
factor is the fact that, because it is a federal program, there is a require- 
ment for considerable reporting to the federal government. Many conservative 
banks are reluctant to participate because they fear that with reporting 
comes control. 

The primary reason why the legislature chose to have the State 
become a lender was because of a survey that was conducted in 1970 which 
revealed that there was a shortage in Florida of 39.5 million dollars for 
financing educational aid. The legislature was convinced that the only way 
to overcome this shortage was to make the DOE a lender and provide the 
funds through the sale of bonds. Since the federal government was 
insuring the loans then, theoretically, there was no way that the state 
could lose money, and at the same time the state would be performing a 
considerable service to students at Florida educational institutions. This 
was an investment in human resources, and it was the first instance that 
the State of Florida had ever sold bonds to finance anything other than 
capital outlay projects. 
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An indication of the high regard held for the Florida Loan Program 
is apparent from the results of the first sale of bonds. The Scholarships 
and Loans Section had anticipated a percentage rate for retiring the bonds 
of 5.5%, and had figured that they could manage at 5.75%. When the bids 
were opened, the successful bid was 4.6%. Of the nine bids, only one 
exceeded 4.75%. 

Computer System Development 

After the legislature had determined that the Department would be- 
come a lender, a search was made nationwide for a computer-based system 
that could be acquired and easily adapted to the Department's needs. 
Of all the systems seen, the system being developed by Wachovia Services, 
Inc., of Winston-Salem, North Carolina, was determined to be the most 
suitable. An agreement was reached whereby the Department would purchase 
the System Specifications and Program Specifications from Wachovia Services 
for $15,000. The System Specifications which were acquired were modified 
by the Information Systems staff in order to tailor them more closely to the 
needs of the Department. 

It was determined that the proper course of action was to develop 
our own System Specifications from those which had been acquired. This 
was done and, in accordance with our project management procedure, the 
specifications were submitted to the users which, in this case, were two: 
the Scholarships and Loans Section and the DOE Comptroller. Following 
approval of the Systems Specifications, the Program Specifications were 
prepared and approved by the users. 

As designed, the system required about sixty computer programs. 
Development of this system represents a projected twenty-seven man months 
of effort, about 70% (19 man months) of which will be expended for programming. 
The programming effort was initiated in late January 1973, and the projected 
completion date is late in May* 

Our Project Management Procedure, together with PERT, has proved to 
be of imneasurable assistance in the development of this system. Some 
of the advantages which they provided were: 

1. All of the benefits to be gained through an orderly, systematic 
Project Management Procedure were realized. The fact that the needs 
of two different user organizations had to be satisfied was 
unique with this system. Many of the problems which could arise 
under such circumstances were avoided because of our adherence to 
this procedure. 

2. PERT forced us to identify all of the activities which were 
required to complete each phase of development. 

3. Having defined the activities and their duration, we then had 
a schedule, thanks to PCS. 

4. PERT provided a vehicle which enabled us to more effectively 
communicate progress to our users. 

5. It also provided in-house information as to the status of the 
project. 

6. PERT gave us something more than intuition on which to base 
decisions. 
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CONCLUSIONS ANB SUMMARY 



Successful project management can be achieved by means of well- 
defined procedures coupled with computer-assisted tools such as PERT/CPM, 
represented by the IBM Project Control System/360. These techniques 
significantly contribute to achievement of the two primary purposes of 
project management: 

1. completion of the project within the schedule, and 

2. control of the cos*", of the project. 

Information Systems of the Florida Department of Education has success- 
fully used these tecnniques in the development of large computer-based 
systems. Beyond the achievement of primary purposes ^ other benefits have 
resulted from their use. They are: (not necessarily in order of importance) 

1. Bridging the user communication gap by means of user participation 
throughout all phases of systems development and implementation. 

2. More effective planning in terms of activities to be accomplished 
and their interrelationships. 

3. The ability to more effectively monitor and control progress 
of projects. 

4. The great benefit of better user and upper management relations 
by meeting commitments expeditiously and efficiently. 

5. A much better product (system) because of better planning and 
monitoring. 

6. Improved future project planning and control because of better 
planning and control presently. 

Good project management procedures and a good project control system 
supported by the computer have made a significant contribution to planning 
and controlling computer-based systems de\felopment in the Florida 
Department of Education. As has been men':ioned, these techniques are not 
foolproof; they do not represent a panacea. There may still be overruns, 
but they will be fewer and to a lesser degree. Therefore, we highly 
recommend these techniques. 
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